Since its inception in 1995, the Java™ programming language has become increasingly popular. (Java is a trademark of Sun Microsystems, Inc.) Java, which is an interpreted language, enabled the creation of applications which could be run on a wide variety of platforms. This ability to function across a variety of different client platforms and Java's relatively easy implementation of network applications has resulted in its use in endeavors as basic as personal web pages to endeavors as complex as large business-to-business enterprise systems.
As Java has become more commonplace, a wide variety of tools and development platforms have been created to assist developers in the creation and implementation of Java applications. These development platforms have usually been built around an application server program that provides a common interface for accessing internal data and resources. These development platforms have also included commonly-used modules and components that can be included in newly-created applications, thus sparing the developers the burden of creating these components and having to recreate the efforts of others. One such application platform is WebLogic Platform, by BEA systems of San Jose Calif.
While these platforms enable users to utilize previously developed modules and components, there are some inefficiencies with the current mechanisms by which these modules are included in new applications. Current configurations require that the modules be copied into every application which utilizes the modules or add the modules to a system classpath storing modules that are available to all applications. Thus, if these commonly-used modules are modified, they must be separately modified in every application which utilizes them, greatly complicating the process of maintaining web servers and complicating deployment.
FIG. 1 illustrates an embodiment of an application deployment environment as practiced in the prior art. A server storage 5 stores multiple applications 10, 15, 20 previous to deployment. The applications are preferably stored as archives for deployment by a deployment tool 25. In one embodiment, the archive is stored in the form of an Enterprise ARchive (EAR) file. Each application includes a set of application modules 30. The application modules 30 are application-specific modules that were generated by a creator of the application 40 for use in the specific application. The application 10 also includes a set of common modules 35. The common modules 35 are modules that have been created by a third party for use in other applications. The common modules 35 can include libraries, administrative web applications, Enterprise Java Beans (EJB's) and any other modules that might be made available for use in multiple applications. Applications 15 and 20 also include common modules. In the present prior art embodiment, any applications that utilize a common module must include a copy of the common module, thus requiring many multiple copies of the common module in the storage.
The application 10 also includes a deployment descriptor 38 which stores information necessary for the deployment tool 25 to successfully deploy the application. In one embodiment, the deployment descriptor is an application.xml file. As used herein, files ending with an “xml” filename extension are files in the eXtensible Markup Language (XML) format. The deployment descriptor preferably includes elements indicating each module used in the application, its type, and its path in the EAR file storing the application. If a common module 35 is used in each of the applications 10, 15, 20 it will appear in each of the EAR files, with its existence and location in the EAR referenced in the deployment descriptor 38 for the applications. The deployment descriptor 38 typically lists the location of the file in the EAR relative to a root of the EAR.
The deployment tool 25 is responsible for deploying the applications 10, 15, 20 from the server storage to generate the deployed applications 40, 45, 50. In one embodiment, the deployment tool runs when the server is started and automatically deploys a group of preselected applications. In an alternate embodiment, the deployment tool allows a system administrator to manually select which applications are deployed. The deployment tool checks the deployment descriptors 38 of each of the applications 10, 15, 20 to locate the modules 30, 35 used by the application within that application's EAR file and to deploy the application. The deployed applications are then available for use by remote clients or any party interacting with the web server.
The implementation discussed in FIG. 1 is inefficient as any modifications made to the common modules must be made in every application. Additionally, as new versions of the common modules are released it becomes difficult to track which versions are in use in each application. What is needed is a more efficient system of implementing commonly used modules.